\section{Lancer une requête}
Nous allons vous expliquer dans cette section comment nous avons
lancé notre programme sur les requêtes.

Voici avant tout le format des fichiers des requêtes :
\begin{lstlisting}
  R ::= Requete
    | C                 Un seul critere
    | C ',' R           Un critere suivie d'une virgule puis de la suite de la requete

  C ::= D '<=' k       Un critere est une borne sur une mesure

  D ::= Distance
    | L '<' u '>'       La distance en largeur entre w et u
    | P '<' u '>'       La distance en profondeur entre w et u
\end{lstlisting}

Par exemple un fichier de requête peut contenir la requête suivante :

{\tt   P <Denis Diderot> <= 2, L <Paris> <= 10 

       P <Objective Caml> <= 2, L <Java> <= 20} \\


Pour optimiser le temps, nous avons d'utiliser le module Lwt~\cite{lwt} pour distribuer le calcul. En effet nous allons donc paralléliser les différents calculs, qu'ils soient en largeur ou en profondeur et une fois que les threads terminent, nous ferons l'intersection des résultats.

Rapidement, on se rend compte que si l'un des calculs termine avec un ensemble vide, il faudrait arrêter les autres threads. C'est là qu'intervient le fameux booléen qui est ajouté aux fonctions {\tt Depth.dfs} et {\tt Breadth.bfs}. Ainsi ce booléen servira de drapeau et s'il prend la valeur {\tt vrai} alors toutes les threads s'arrêtent et renvoie un ensemble vide. \\
Ainsi nous avons pu constater un gain de performance {\bf vraiment non négligeable}.

Par contre, nous avons décidé de ne pas paralléliser les différentes requêtes, car cela ralentissait le réseau et la connexion, donc nous avons constaté une baisse de performance. Peut-être qu'avec la fibre optique, cela serait réalisable sans perte de performance.

De plus on peut remarquer qu'avec cette syntaxe, il se peut qu'on trouve deux fois le même critère sur la même ligne, où deux fois le même mais avec une profondeur ou une largeur différente. Par exemple :

{\tt   P <Boston> <= 2, P <Boston> <= 2, L <Red Sox> <= 34 

       L <Los Angeles> <= 24, P <Paris> <= 2, L <Los Angeles> <= 30} \\

Avant de lancer nos requêtes, notre parser pour ce type de fichier avec cette syntaxe précise, nous renvoie un arbre de requête contenant les différents critères. Nous faisons tout simplement un pré-traitement des requêtes en supprimant les doublons et en ne gardant que les requêtes donc la pronfondeur ou la largeur est la plus petite. Comme l'étape des requêtes est suivies d'une grande intersection entre les différents ensemble retournés, cela semble la bonne solution pour ne pas perdre de temps avec les mêmes critères dans une même requête.

Pour finir nous avonc décidé pour le moment d'éliminer les requêtes de type :
\begin{itemize}
  \item $[A|a]$ ide: ...
  \item $[P|p]$ rojet: ...
  \item $[W|w]$ ikipédia: ...
  \item $[P|p]$ ortail: ...
  \item $[M|m]$ odèle: ...
  \item $[D|d]$ iscussion utilisateur: ...
\end{itemize}